The use of computers to model business processes has become ubiquitous. Software applications that manage every aspect of a business are readily available. Applications that manage human resources, access to information technology resources, benefits, accounting, payroll, resource management, and almost any other aspect of a business are in use today and form an important part of the operation of almost any business.
Many typical business applications represent business processes through the use of objects. For example, an employee may expend funds on behalf of the organization and submit an expense report to receive reimbursement. In some cases, the expense report may be a physical form that the employee fills out, while in other cases the employee may fill out the expense report electronically. One common method of receiving an employee expense report may be to provide a web page that the employee may direct his web browser to in order to enter information about the expense. The information about the expense may then be entered into an accounts payable system, either directly from an electronic source, such as the web page, or manually through a data entry process. An accounts payable system may model this expense as an object. As is known in the art of object oriented programming, an object may be an electronic representation of a collection of related data that may be manipulated as a single entity. For example, the expense report object may contain an amount of the expense, the employee who paid the expense, the entity that received the payment, and any other information that would be necessary to process the expense. Encapsulating all of the data that makes up an expense into a single object may allow the accounts payable system to simplify processing of the expense because individual data elements that make up the expense no longer need to be correlated with each other. All data related to a given expense may be treated as a single entity.
Typically, the expense object may have a state, and as the expense object is processed, the state may change. For example, when the employee begins the process of entering an expense for reimbursement, an expense object may be created, thus changing, or creating, a state of the expense object from “DOES NOT EXIST” to “CREATED.” After the employee has entered any necessary information to process the expense, such as reasons for the expense, amount, etc., the employee may submit the expense to the accounts payable system. At this point, the accounts payable system may change the state of the object from “CREATED” to “SUBMITTED.”
As part of the process of paying an expense, an approval for the expense may be required. For example, the employee's supervisor may need to review the expense and determine if it is appropriate for the expense to be paid. The accounts payable system may send a notification to the supervisor, perhaps through an e-mail message, indicating that an expense requiring approval needs to be processed. The supervisor may then review the expense, and if appropriate, approve the expense. Notification of the approval may then be returned to the accounts payable system. The accounts payable system may then move the expense object from a “SUBMITTED” state to an “APPROVED” state. Alternatively, in the case where the expense is not approved, the expense objet may be moved to a “REJECTED” state, and the employee may be notified his expense was rejected.
In the normal flow however, the expense will be approved. At this point, the accounts payable system may cause a payment to be issued to the employee. After the payment is issued, the accounts payable system may move the expense object from an “APPROVED” state to a “PAID” state. The movement between states of a business object within an isolated application, such as an accounts payable application, is a relatively straightforward process. In some implementations, a business application may make use of a state engine to keep track of the current state of the business object and actions to be performed within that state prior to moving to a next state. In the present example, the normal flow of the expense object would be to start in the “CREATED” state. Once the employee submits the expense, the state engine may move the expense object to the “SUBMITTED” state. In that state, the state engine may be programmed to request an approval from a supervisor. The state engine may keep the expense object in the “SUBMITTED” state until the approval is received, at which point the expense object is moved to the “APPROVED” state. In the “APPROVED” state, the state engine may request a payment, and once issued the expense object may be moved to the “PAID” state.
As mentioned above, use of a state engine in an isolated business application is relatively straightforward. However, business applications operating in isolation in today's business environment are increasingly rare. Typically there are many different applications involved in running a modern business, and each application may require information from other applications. For example, the expense discussed above may have been paid in relation to fulfilling an obligation related to a business contract. In such cases, a contracts application may need to be informed to indicate that the obligation has been met. In addition, the expense may have been related to completion of a project, such that a project management application may need to be informed.
To add further complexity, situations may arise wherein an external application may need to prevent a state change within the instant application. For example, an expense object may be in the “APPROVED” state. As far as the accounts payable system is concerned, the expense should be paid because it has been approved, and the expense object moved to the “PAID” state. However, an external application, such as a contracts application, may have a reason that the expense should not be paid. Perhaps the contract related to the expense is in default, and as such, no payments should be made. Thus the contracts application requires a mechanism to prevent the accounts payable application from moving the expense object to the “PAID” state until an approval is received from the contracts application.
Attempts at providing a solution to the above described scenario are less than ideal. In some solutions, a seemingly endless string of “if-then” conditions may be embedded in an application's state engine. For example, if the above described scenario, the transition from the “APPROVED” state to the “PAID” state may require determining if a contracts application is installed, and if so, notifying the contracts application, and waiting for a response. Similarly, this condition may be repeated for any number of other applications. Some external applications may just need to be notified of the impending state change, while others, such as the described contracts application, may need to be able to actually prevent the state change from occurring.
As should be clear, such solutions are not ideal for a number of reasons. One reason is that every time a new external application is installed, the host application must be modified if the external application wishes to interface to with the host application. Another reason the solution is not ideal is from a standpoint of software maintainability for the host application. A seemingly endless series of checks to determine which external applications are installed, which external applications may need to be notified of state changes, and which external applications may need the ability to prevent a state change, leads to increasingly complex software code within the application that is very difficult to maintain. Furthermore, all of the additional complexity required for interfacing with the external applications does nothing to improve the operation of the host application.
Embodiments of the present disclosure attempt to solve problems such as those mentioned above, as well as others that would be readily known to one of skill in the art.